clean architecture
https://gyazo.com/fd3da26b05cc90c0ef3e4d41bac95c95
有名なパラダイムと設計原則についてまとまっててまあ良いんじゃないか
わざわざ買って読むか悩んでいたが、clojureを本の中で推しているらしいので買った
わかりやすい実装例
逆に言うと、defmultiを備えてなかったり、それを代わりにこなすライブラリが無い言語で必死にクリーンアーキテクチャするの、苦行では？
その言語が十分な表現力を備えてないのに、それを実現しようとしてるような
どれほどそれが、依存関係を綺麗にできても、そのようにするためにコードがぐちゃぐちゃになったら開発体験が悪くなるでしょう
miyamonz.iconの読む前の感想
読む前にかけるくらい、ネット上でクリーンアーキテクチャは議論されている
レイヤーを分けるのはきれいだと思うが、それが常に有効だとは思っていない
導入ができなかったという話
レイヤーをわけようとしてるのに、特定のDBのSQL呼び出し見いたいなメソッドが生えたら意味がない
これは、言語上のレイヤーは別れているが、概念の抽象をできていない状態
リポジトリ層を雑にインメモリかファイルに保存して最初は開発して、リポジトリ層のインターフェースをドメイン層が一番わかりやすく直感的に書けるように定義して、その後にDB実装に切り替えるのは良さそう
最初からDBアクセスのパフォーマンスが大きく関わるなら違うアプローチが必要かもしれん
１ 設計とアーキテクチャ
開発が進むと、人数が増えて、規模も増えていく
コストと時間がかかる
複雑性がまして言っている
２ ２つの価値のお話
振る舞いと構造
振る舞い
ソフトウェア
ソフト、変更が可能
完璧に動作するが、変更できないプログラムでは役に立たない
動作しないが、変更が可能
これは、修正することで動かすようにできる
変更できないプログラムなど無いが、変更コストがメリットを上回り、事実上動かせなくなる
設計は重要
ふるまいは緊急
３ パラダイムの概要
さまざまなパラダイム
構造化プログラミング
単なるgotoからのif,then,else, do,whileなど
直接的な制御の移行に規律を課す
オブジェクト指向プログラミング
間接的な制御の移行に規律を課す
関数型プログラミング
代入に規律を課す
と筆者は言っているがmiyamonz.icon
わかるようなわからんような
３つのパラダイムは、我々からこれを奪うためのもの
goto
関数ポインタ
代入
1958-1968の１０年間で上記の３つのパラダイムが生まれて、それ移行追加されてないという
コンポーネントの分離
データ管理
機能
４ 構造化プログラミング
Dijkstra
gotoのせいでモジュールにワケられないことに気づいた
うまく使えばできた→ここが反復制御に対応すると気づいた
順次、選択、反復
gotoが有害であるという論文を書いた
最初１０年は論争になったらしい
今日では、実際gotoは消えた
機能分割
５ オブジェクト指向プログラミング
曖昧
一つの答えに、データと関数の組み合わせ
これはばかばかしい。昔から、データ構造を関数に渡していた
o.f()とf(o)を別物と見なすのは変
２つめ 現実の世界をモデル化する方法
定義が雑すぎる
よくある用語
カプセル化、継承、ポリモーフィズム
これらをOOの性質として、OO言語はこれをサポートするべき、という話もある
用語整理
カプセル化
C言語で実例
継承
継承とは、スコープ内の変数と関数のグループを再度宣言したもの
Cは手動でやってきたこと
手動で書いても、フィールドの順序を守っているから成り済ませる
つまりC言語でも昔は、言語のサポートは無いもののやっていたこと
OO以前からプログラマがやっていたプラクティス
とはいえ、当然トリックとして使っていたので不便ではあった
OOのおかげで、データのなりすましはやりやすくなった
ポリモーフィズム
OO以前にもあった
Cの例
STDINとSTDOUT
これはポリモーフィズムを実現している
getchar()はSTDINがさしているFILEデータ構造体のreadポインタが指している関数を呼び出している
これがOOのポリモーフィズムの基礎
c++もvtableというテーブルにポインタを持ち、仮想関数の呼び出しをテーブルを介して切り替える
つまり、関数ポインタの応用
もちろん、より安全にこの機能を提供できるようにしたのがポリモーフィズムと言えるので、まったく新しくないわけではない
ポリモーフィズムのパワー
６関数型プログラミング
clojureが出てきた
javaは可変変数があるが、関数型には無い
というのは違って、可変のものはそれ用のデータ型がある
append onlyな話
イベントソーシング
第三部
設計の原則